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Abstract 

xGiotto  [5]  is  a  domain  specific  language  for  the  implementation  of  embedded  soft¬ 
ware  applications  with  hard  temporal  constraints.  The  language  is  an  extension  of 
the  original  GlOTTO  language  [6].  In  this  report  we  present  the  xGlOTTO  tool  chain, 
composed  of  the  compiler  and  a  specialized  virtual  machine,  Embedded  Virtual  Ma¬ 
chine  (EVM).  The  compiler  checks  for  determinism  (absence  of  races)  and  time  safety 
(schedulability  within  logical  execution  times)  and  generates  code  for  EVM.  The  EVM 
integrates  an  event  filter  (which  handles  aperiodic  asynchronous  events  and  event  scop¬ 
ing  introduced  in  [5])  and  a  modified  Embedded  Machine  [7].  The  report  presents  the 
instruction  set  and  the  operational  semantics  of  the  virtual  machine.  The  report  also 
presents  event  calculus  which  is  used  to  extend  expressiveness  of  xGlOTTO.  The  re¬ 
port  concludes  with  a  case  study  of  implementing  an  automotive  engine  controller. 


Chapter  1 

Introduction 


Real-time  systems  for  embedded  applications  are  characterized  by  limited  memory, 
distributed  nodes,  interprocess  communication,  fast  context  switches  and  concurrency  [1] 
However  the  most  important  features  of  such  systems  are  predictability  and  timing. 
The  execution  of  a  safety  critical  system  must  be  predictable  and  the  evaluation  of  a 
task  should  be  available  when  it  is  due  (neither  before  the  deadline  nor  after).  Several 
programming  paradigm  has  been  used  for  implementing  real-time  controllers.  In  [2] 
real-time  systems  programming  has  been  divided  into  three  categories:  scheduled,  syn¬ 
chronous  and  timed.  The  first  approach  is  the  traditional  scheduling  based  approach  [3] 
where  each  task  is  assigned  a  priority.  The  second  approach  is  programming  with  syn¬ 
chrony  assumption  [4]  where  all  tasks  are  assumed  to  execute  in  logical  zero  time. 
In  [5]  it  has  been  argued  that  while  the  first  approach  causes  non-determinism  making 
program  verification  difficult,  the  second  approach  is  not  suitable  for  applications  with 
non-negligible  task  execution  and  distributed  computing. 

The  third  programming  approach  assumes  that  each  task  is  associated  with  a  Logical 
Execution  Time  (LET)  [5,  6].  When  a  task  is  released  on  a  platform  its  correspond¬ 
ing  LET  is  specified  by  a  termination  event.  The  task  output  is  available  only  when 
the  termination  event  occurs.  Even  if  the  task  completes  its  execution  before  the  ter¬ 
mination  event  arrives,  the  task  output  is  not  released.  A  trace  of  the  execution  is 
time-safe  if  all  tasks  released  along  the  trace  completes  their  execution  before  the  ar¬ 
rival  of  the  respective  termination  event.  A  program  is  schedulable  if  all  the  traces  are 
time-safe.  The  LET  model  makes  the  program  execution  time-deterministic  (no  jitter) 
and  value-deterministic  (no  race  conditions)  and  thus  make  program  verification  and 
analyses  easier  than  the  traditional  scheduling  model.  Details  about  the  LET  model 
and  corresponding  advantages  in  using  LET  model  has  been  discussed  in  [5,  6,  7,  2,  8]. 
The  LET  programming  model  has  been  studied  and  implemented  on  different  plat¬ 
forms.  In  [6]  we  present  GlOTTO,  a  time-triggered  version  of  the  LET  programming 
model.  Our  first  implementation  [9]  was  done  on  top  of  a  conventional  real-time  oper¬ 
ating  system  (Eigure  l.l.A)  like  Osek  [10]  and  HelyOS  [11].  By  using  a  programming 
paradigm  where  timing  and  functionality  are  separated  [6,  7],  we  were  able  to  focus  on 
the  compiler  and  the  E  Machine  implementations  leaving  the  platform  specific  prob¬ 
lems  to  the  real-time  operating  systems  (RTOS).  The  E  Machine  (or  the  Embedded 
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Machine)  [7]  is  the  virtual  machine  on  which  GlOTTO  was  implemented.  In  [12]  we 
extended  the  previous  implementation  by  introducing  the  E  Machine  in  the  RTOS  itself 
(Figure  1.1. B)  in  order  to  gain  flexibility  and  to  reduce  the  overhead  of  the  operating 
system.  In  this  paper  we  present  another  approach  (Figure  1 . 1  .C)  for  implementing  the 
FET  programming  model,  by  integrating  the  E  Machine  directly  into  the  instruction 
set  of  the  running  CPU.  Since  we  are  not  able  to  produce  a  silicon  for  the  associated 
high  cost  and  our  limitation  of  time,  we  choose  to  modify  an  instruction  set  simulator 
to  implement  a  modified  E  Machine  instructions.  For  its  simplicity  and  popularity,  the 
Java  Virtual  Machine  [13]  was  chosen. 


Figure  1.1:  Implementing  the  FET  programming  model 

xGiotto  [5]  is  a  high-level  programming  language  for  control  applications.  GlOTTO 
is  the  predecessor  of  xGlOTTO.  While  GlOTTO  can  express  only  time-triggered  sys¬ 
tems,  xGiotto  handles  aperiodic,  asynchronous  events  and  hence  can  implement 
event-triggered  applications.  Besides,  xGlOTTO  introduces  a  new  approach  based  on 
the  notion  of  event  scoping,  which  allows  us  to  encode  an  implicit  environment  as¬ 
sumption  in  xGiotto  programs.  Event  scoping  temporarily  disables  event  monitoring 
for  a  subset  of  the  observed  events.  In  this  way,  the  environment  assumption  is  reflected 
by  the  control  structure  of  the  program  itself.  An  xGlOTTO  program  is  compiled  and 
checked  whether  the  program  is  free  of  races  and  is  schedulable.  Next  the  code  gener¬ 
ator  produces  machine  level  code  which  can  run  on  a  virtual  machine.  GlOTTO  runs  on 
the  virtual  machine  E  Machine.  However  the  E  machine  is  not  capable  of  handling  the 
event  scoping  and  functionality  code  of  xGlOTTO.  This  paper  discusses  the  Embedded 
Virtual  Machine  (EVM)  which  implements  an  event  filter  (for  event  scoping)  and  a 
modified  E  Machine  which  runs  parallel  to  a  scheduler.  In  the  future  the  scheduler  will 
be  integrated  with  the  EVM.  The  code  (or  the  instruction  set)  for  the  EVM  is  called 
EVM  code. 

In  the  next  chapter  a  brief  discussion  of  xGlOTTO  and  its  notion  of  event  scoping  has 
been  presented.  This  is  followed  by  the  description  of  an  event  calculus.  Event  calcu¬ 
lus  complements  the  notion  of  event  scoping  introduced  in  [5].  The  chapter  concludes 
by  an  example  of  an  xGlOTTO  program  and  the  corresponding  EVM  code.  Chapter  3 
introduces  the  instruction  set  for  EVM  and  details  the  semantics  of  the  operation  of  the 
EVM.  Chapter  4  presents  the  compile-  and  run-time  implementation  of  the  xGlOTTO 
tool  chain  and  presents  the  possible  future  extensions.  Chapter  5  presents  the  imple¬ 
mentation  of  a  controller  for  an  automobile  engine  in  xGlOTTO.  Chapter  6  concludes 
the  report. 
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Chapter  2 

xGiotto 


xGiotto  (like  its  predecessor  GlOTTO)  is  built  around  the  notion  of  LET  model  of 
task  execution.  In  GlOTTO  an  event  is  always  a  clock  tick  and  thus  the  release  and 
termination  of  a  task  is  possible  only  at  clock  ticks.  However  xGlOTTO  being  event- 
triggered  an  event  can  be  either  a  clock  tick  or  an  arbitrary  sensor  interrupt.  GlOTTO 
does  not  allow  simultaneous  execution  of  multiple  instances  of  the  same  task;  however 
xGiotto  does  not  have  this  limitation.  An  event  in  xGioTTO  has  two  possible  actions: 
invoking  a  reaction  block  or  terminating  a  reaction  block.  A  reaction  block  defines  a 
set  of  triggers  and  a  set  of  tasks  and  has  a  termination  event.  A  trigger  maps  an  event 
to  a  set  of  reaction  blocks  such  that  when  the  event  occurs  the  reaction  blocks  are 
activated.  A  task  is  a  functional  code  similar  to  a  procedure.  When  a  reaction  block 
is  activated  it  enables  the  triggers  and  releases  the  tasks.  When  a  reaction  block  is 
terminated  (on  arrival  of  its  termination  event)  the  associated  tasks  are  also  terminated. 
Thus  the  active-time-span  of  a  reaction  block  denotes  the  LET  for  the  tasks  released 
by  it.  The  execution  of  a  reaction  block  is  done  synchronously,  i.e.  executed  in  logical 
zero  time.  However  the  execution  may  take  place  at  different  time  instants  if  there  are 
nested  reaction  blocks. 

The  events  associated  with  a  reaction  block  are  the  events  of  the  triggers  and  the  ter¬ 
mination  event  of  the  block.  This  is  the  event  scope  for  the  reaction  block.  When  a 
reaction  is  invoked  (one  of  the  triggers  is  triggered)  the  called  reaction  becomes  the  ac¬ 
tive  scope  and  the  callee  reaction  (the  passive  scope)  is  pushed  onto  a  stack.  However 
as  parallel  invocation  of  reactions  are  allowed,  a  tree  of  scopes  may  exists  at  any  instant 
of  the  execution.  The  leaves  of  the  tree  are  the  active  scopes  and  the  non-leaf  nodes 
are  the  passive  scopes.  An  event  in  passive  scope  can  be  handled  as  follows:  ignored, 
remembered  or  acted  upon  as  soon  as  possible;  they  are  specified  by  the  keywords: 
forget,  remember,  and  asap.  If  an  event  is  remembered,  the  associated  action  is 
taken  when  the  corresponding  scope  becomes  active  again.  If  an  asap  event  occurs 
the  trigger  queues  of  the  sub-tree  rooted  by  the  scope  is  emptied  so  new  trigger  action 
can  take  place.  The  scopes  are  not  preempted  immediately  to  avoid  unsafe  termination 
of  tasks. 
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Language  Constructs. 

An  xGioTTO  program  consists  of  a  set  of  ports  P,  events  E,  tasks  T,  and  reaction 
blocks  R.  A  port  declaration  for  a  port  (or  a  program  variable)  consists  of  a  name,  a 
fixed  type  and  an  initial  value.  An  event  declaration  for  an  event  consists  of  an  event 
name,  type,  and  the  external  interrupt  triggering  the  event.  The  events  time  and  now 
are  predefined;  time  corresponds  to  the  system  clock  while  now  is  a  placeholder  for 
current  event  and  cannot  be  used  as  a  termination  event  for  reaction  blocks.  Multi¬ 
ple  events  can  be  combined  to  express  environment  assumptions  in  an  efficient  and 
succinct  manner  in  an  xGlOTTO  program.  However  it  is  assumed  that  no  two  events 
can  occur  simultaneously.  The  expressiveness  of  event  has  been  extended  by  an  event 
calculus  presented  below.  A  task  declaration  for  a  task  consists  of  a  task  name,  input 
parameters,  output  parameters  and  local  variables.  The  task  body  is  a  standard  sequen¬ 
tial  program.  A  reaction  block  declaration  for  a  reaction  block  consists  of  a  name, 
a  body  and  an  termination  event  parameter.  The  body  of  the  reaction  block  consists 
of  trigger  statements,  release  statements  and  sequential  reaction  statements.  The  con¬ 
struct  for  trigger  statement  is  when  [e]  r  where  event,  e  G  E  and  r  is  a  reaction. 
The  statement  denotes  that  when  e  arrives  the  reaction  r  is  invoked.  The  reaction  r 
may  be  a  single  reaction  block  or  multiple  reaction  blocks  composed  in  parallel.  The 
types  of  parallelism  are:  wait-  and  a  sap-parallelism.  If  a  scope  bound  in  asap- 
parallelism  terminates,  the  triggers  of  the  sibling  scopes  and  the  sub-tree  rooted  by 
them  are  removed.  If  a  scope  bound  in  wait-parallelism  terminates,  no  further  action 
is  taken.  The  construct  for  release  statements  is  release  t  (in)  (out) .  It  re¬ 
leases  a  new  task  instance  for  task  t.  When  the  task  is  released  the  values  of  input  ports 
in  are  copied  to  the  local  ports  of  the  task  instance  and  at  task  termination  the  output 
ports  out  are  updated.  The  trigger  and  release  statements  can  be  made  conditional  by 
attaching  a  predicate  on  the  ports.  If  the  predicate  is  true  at  the  instance  of  reaction 
block  invocation,  the  corresponding  statement  is  executed. 

xGiotto  Analysis. 

The  xGiotto  compiler  performs  three  analyses  on  xGiotto  programs.  Race  con¬ 
dition  check  and  resource  size  prediction  are  platform  independent  analyses  while 
schedulability  is  a  platform  dependent  analyses.  A  program  is  said  to  have  race  condi¬ 
tion  if  a  port  is  updated  by  two  or  more  terminating  task  instances  at  the  same  instance. 
Race  conditions  are  undesirable  as  they  give  rise  to  non-determinism  in  the  program 
execution.  At  present  the  xGlOTTO  compiler  checks  for  race  by  a  reachability  algo¬ 
rithm  which  is  PSPACE-complete.  The  resource  size  analysis  predicts  the  memory 
requirements  for  executing  the  program  on  a  real-time  platform.  A  conservative  bound 
can  be  found  in  time  linear  to  the  size  of  the  program.  Schedulability  for  an  xGlOTTO 
program  checks  whether  a  given  program  is  schedulable  or  not  with  respect  to  a  real¬ 
time  platform  (given  by  the  worst-case-execution-time  mapping  of  the  tasks  to  the  plat¬ 
form).  Schedulability  of  an  xGlOTTO  program  can  be  defined  as  a  two-player  safety 
game  between  the  system  and  the  environment.  The  program  is  schedulable  if  in  this 
game  the  scheduler  has  a  strategy  to  avoid  time-safety  violations  forever.  In  theory  the 
schedulability  problem  is  complete  for  EXPTIME.  Refer  [5]  for  details  of  the  analyses. 
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2.1  Event  Calculus 


The  event  calculus  defines  two  types  of  events:  atomic  events  and  compound  events. 
An  atomic  event  is  an  event  which  is  triggered  by  a  sensor  interrupt.  For  the  event 
declaration  e  AT  sensor_interrupt,  e  is  an  atomic  event  triggered  by  an  exter¬ 
nal  interrupt  sensor_interrupt.  A  compound  event  is  an  expression  on  atomic 
events  and  compound  events  using  the  sequence  operator  (•)  and  either  operator  (V)  as 
follows: 

E::=e\E-E\E\/E  (2.1) 

where  E  is  an  compound  event  and  e  is  an  atomic  event.  The  sequence  operator  de¬ 
notes  that  the  associated  action  takes  place  only  if  the  events  occur  serially  in  the  order 
defined.  The  either  operator  denotes  that  either  of  the  events  has  to  occur  for  triggering 
the  associated  action.  The  order  of  precedence  for  evaluating  a  compound  event  is: 
brackets,  sequence  operator  and  either  operator.  A  concrete  compound  event  E  can  be 
expressed  as  a  finite  state  machine  whose  edges  are  labelled  with  atomic  events  and 
the  compound  event  is  enabled  if  an  accepting  state  of  the  state  machine  is  reached. 
If  a  concrete  compound  event  consists  of  only  an  atomic  event  then  the  corresponding 
state  machine  consists  of  one  initial  state,  one  accepting  state  and  one  transition  from 
the  initial  state  to  the  accepting  state  labelled  by  the  atomic  event.  The  event  calculus 
is  closed  under  the  sequence  and  either  operators  and  can  be  proved  by  construction. 
In  the  Figure  2.1  events  A,  B  and  C  are  atomic  events  triggered  by  interrupt.!,  inter- 
rupt_2  and  interrupt_3  respectively. 


Evente^ressionforA,BandC  '  A.BvCA 


Figure  2.1:  Event  Calculus 


Three  derived  operators  are  also  defined  in  the  event  calculus  for  succinct  representa¬ 
tion.  They  are  the  repetition  operator  (*),  in-any-order  operator  (#)  and  interleaving 
operator  (:).  Thus  the  extended  calculus  is 

E\-=e\E-E\EyE\k*E\  E#E  \ki*e\k2*e  (2.2) 

where  k,ki,k2  are  integer  constants.  The  repetition  operator  denotes  that  an  event  oc¬ 
curs  for  k  times  and  can  be  expressed  by  applying  the  sequence  operator  k  times.  The 
in-any-order  operator  denotes  that  the  two  events  should  occur  but  in  any  order  and  can 
be  expressed  with  the  sequence  and  either  operators.  Thus  Ei#E2  =  Ei  •  £2  V  £2  •  El  ■ 
The  interleaving  operator  denotes  the  interleaving  of  ki  instances  of  first  atomic  event 
and  k2  instances  of  second  atomic  event.  Thus  for  the  Figure  2. 1  the  compound  event 
2*A  :  2  *B  denotes  any  one  of  the  sequences  {AABB,  ABAB,  BABA,  BBAA}. 
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2.2  Implementing  an  answering  machine 


We  present  a  simple  automated  email  and  phone  answering  machine.  The  system 
replies  to  an  email  or  answers  the  phone  as  follows:  if  either  a  phone  or  an  email 
arrives  when  the  system  is  idle  the  corresponding  task  is  performed;  if  an  email  ar¬ 
rives  during  answering  the  phone  call  or  reading  another  email  it  is  remembered  and 
is  handled  as  soon  as  the  phone  call  has  been  answered  or  the  current  email  has  been 
read;  however  if  a  phone  call  arrives  when  answering  an  email  or  a  phone  call,  the  new 
phone  call  is  ignored. 

The  xGioTTO  code  for  implementing  this  machine  has  been  shown  in  the  Figure  2.2. 
The  program  implements  two  tasks,  one  for  reading  the  emails  and  one  for  answering 
the  phone.  The  input  and  output  ports,  and  the  body  of  the  tasks  have  been  omitted 
for  simplicity.  The  code  consists  of  two  trigger  statements:  one  for  the  email  event 
and  the  other  for  the  phone  event.  When  an  email  arrives,  an  email  event  is  raised 
and  the  task  readmail  is  released.  The  readmail  task  processes  the  email  and 
terminates  at  the  arrival  of  the  done  event.  Similarly  at  the  arrival  of  a  phone  call 
—  signaled  by  the  phone  event  —  the  task  answerphone  answers  the  phone  and 
terminates  the  execution  when  the  caller  hangs  up  (event  hangup).  The  desired  event 
handling  is  embedded  by  using  the  keywords  remember  with  email  and  forget 
with  phone.  Thus  event  email  will  be  remembered  if  the  system  is  busy  and  would 
be  handled  as  soon  as  the  system  becomes  idle;  however  if  an  event  phone  arrives 
when  the  system  is  busy  the  event  is  ignored. 


task  readmail  /*action*/ 
task  answerphone  /*action*/ 

react  { 

whenever  remember  [email] 
react  { 

release  readmail  ()  ( ) ; 

}  until  [done] ; 
whenever  forget  [phone] 
react  { 

release  answerphone])  (); 
}  until  [hangup] ; 

} 


Task  Table: 

0  :  return  //readmail function 
1 :  return  //answerphone function 


Code 


0  : 
1 : 

2  : 

3: 
4  : 
5: 
6: 

7  : 

8  : 
9: 


enterscope 
when  repeat, 
[email] 
when  repeat, 
[phone ] 
exitscope 
enterscope 
release  #0 
exitscope 
enterscope 
release  #1 
exitscope 


//main  reaction 
remember, 

,  @5,  [done] 
forget , 

,  @8,  [hangup] 

//reaction  to  email 
//task  readmail 

//reaction  to  phone 
//task  answerphone 


Figure  2.2:  xGiotto  Code 


Figure  2.3:  EVM  Code 


The  xGiotto  compiler  generates  code  for  the  EVM.  The  EVM  is  a  mediator  between 
physical  events  and  software  processes:  it  executes  EVM  code  which  reacts  to  events 
and  handles  software  processes.  The  EVM  code  for  the  xGlOTTO  program  presented 


6 


in  Figure  2.2  is  presented  in  Figure  2.3.  The  EVM  code  begins  with  a  table  of  all  the 
tasks  and  their  functionality  code.  For  simplicity  we  have  omitted  the  functionality 
code  and  the  EVM  code  for  the  two  tasks  is  composed  only  of  return  statements.  The 
EVM  code  for  the  reactions  follows  the  task  table.  The  instruction  at  address  0  starts 
the  execution  of  the  main  (starting)  reaction.  The  instruction  enterscope  instructs 
the  EVM  to  allocate  a  new  scope  for  the  reaction.  The  EVM  interpreter  (Algorithm  5) 
will  then  execute  all  instructions  until  the  instruction  ex  it  scope  is  executed.  The 
when  instructions  at  address  1  and  2  declares  two  reaction  invocations;  one  for  the 
email  event  and  one  for  the  phone  event.  The  repeat  keyword  implies  that  the 
trigger  is  to  be  repeated,  i.e.,  belongs  to  a  whenever  statement.  The  [email]  and 
[phone]  specify  the  triggering  event,  followed  by  the  address  of  the  corresponding 
reaction  code  to  be  invoked.  The  last  parameter  of  the  instruction  specifies  the  termina¬ 
tion  event.  The  release  instruction  releases  a  task;  the  parameter  of  the  instruction 
specifies  the  index  of  the  task  in  the  task  table.  Thus  the  instruction  at  address  5  re¬ 
leases  the  task  at  index  0,  i.e.  the  task  readmail. 


7 


Chapter  3 

Embedded  Virtual  Machine 


The  Embedded  Virtual  Machine  is  a  virtual  machine,  similar  to  the  E  Machine,  that  me¬ 
diates  between  the  physical  and  the  software  process  of  an  embedded  system  through 
a  control  program.  While  E  Machine  interprets  E  code,  EVM  interprets  EVM  code. 
An  EVM  program  consists  of  (1)  a  set  P  of  program  ports,  (2)  a  set  E  of  events,  (3)  a 
set  T  of  task  declarations,  and  (4)  a  set  A  of  addresses  and  for  each  address  a  finite  se¬ 
quence  of  instructions.  Besides  interpreting  the  EVM  instructions  (described  below), 
the  EVM  keeps  a  dynamical  data  structure  of  the  event  scopes  defined  in  Section  2. 
The  data  structure  is  implemented  as  a  tree  of  event  scopes  where  each  event  scope 
stores:  the  termination  event  of  the  scope,  a  trigger  queue,  a  set  of  released  tasks,  the 
mode  of  parallel  invocation,  i.e.,  asap-,  or  wait -parallel,  and  a  link  to  all  its  children 
scopes.  Eor  efficiency,  all  active  scopes,  i.e.,  the  leaves  of  the  event  scope  tree,  are 
linked  together. 

3.1  Instruction  Set 

The  instruction  set  of  the  EVM  is  an  augmented  version  of  the  Java  Virtual  Machine 
(JVM)  instruction  set.  A  list  of  the  added  instructions  with  the  opcode  in  the  paren¬ 
thesis  is  provided  below.  The  operational  semantics  of  each  instruction  is  given  by  the 
interpreter  of  Algorithm  5.  Eor  the  full  instruction  set  we  refer  to  [13]. 


(opcode) 

instruction 

synopsis 

(0xE3) 

trigger 

inserts  a  trigger  in  the  trigger  queue 

Q  of  the  actual  event  scope 

(OxEO) 

release 

releases  a  task  to  the  task  instances 
set  T  of  the  actual  event  scope 

(0xE9) 

getport 

writes  on  the  stack  the  value  of  a  port 

(OxEA) 

getevent 

writes  on  the  stack  the  value  of  an  event 

(OxEB) 

putport 

writes  the  value  on  the  stack  to  a  port 

(0xE4) 

enterscope 

generates  a  new  scope,  and  initializes  the  trigger  queue 
and  the  set  of  task  instances:  Q  =  <l),T  =  0 

(0xE5) 

exitscope 

returns  from  the  scope 

3.2  Operational  Semantics 

The  execution  of  an  xGlOTTO  program  yields  a  possibly  infinite  sequence  of  program 
configurations.  A  (program)  configuration  is  the  current  state  of  the  program  execution 
and  consists  of  a  program  counter,  values  of  the  ports,  tree  of  scopes  and  a  stack. 
Formally  a  program  configuration  is  a  tuple  {'L,A,PC,S,SP),  where  E  is  a  function 
from  the  port  set  P  to  values,  A  is  a  labeled  tree,  where  each  node  is  labeled  by  a  scope, 
PC  is  the  program  counter,  5  is  a  stack,  and  SP  is  the  stack  pointer.  A  scope  is  a  tuple 
{U,Q,T,a),  where  U  is  the  termination  event  instance,  Q  is  a  queue  of  triggers,  T 
is  a  set  of  task  instances,  and  a  G  {asap,wait}  is  the  parallelism  of  the  scope  (with 
respect  to  its  siblings).  An  event  instance  is  a  pair  i  =  {e,s,f),  where  e  is  an  compound 
event,  s  is  a  state  of  the  automaton  e,  and  f  '■  f  G  is  the  event  qualifier,  with 

A,R,F  denoting  asap,  remember,  and  forget.  An  event  instance  is  enabled  when 
s  is  an  accepting  state  of  the  compound  event  state  machine  e.  Given  an  atomic  event 
e'  the  operation  next{i,e')  =  i'  where  i'  =  {e,s\f)  such  that  {s,s')  is  a  transition  in  e 
and  labeled  with  e'\  otherwise  i'  =  {e,s,f).  The  operation  reset{i)  resets  s  to  the  initial 
state  of  the  state  machine  e.  A  trigger  queue  is  a  queue  of  triggers.  A  trigger  is  a  tuple 
{i,m,p,r),  where  i  is  an  event  instance,  m  :  m  =  {when, whenever}  is  the  repetition 
parameter,  p  €  {||,&&}  is  the  parallel  operator  (||  denotes  asap-  and  &&  denotes 
wait-parallelism)  and  r  is  a  reaction,  i.e.,  a  set  of  reaction  blocks  to  be  invoked  by  the 
enabled  event  instance.  A  task  instance  consists  of  the  tuple  {t,po,Sp.)  which  implies 
that  the  ports  po  are  updated  (at  task  termination)  by  the  evaluation  of  the  task  t  on  the 
state  of  ports  pi  at  the  instance  of  invocation  (given  by  Sp-). 

A  pseudo  code  description  of  the  EVM  is  provided  here.  Algorithm  1  shows  the  main 
loop  of  the  machine.  Initially  the  active  scope  corresponds  to  the  starting  scope  of 
the  EVM  code  program.  Whenever  an  event  occurs,  the  trigger-related  interrupts  are 
disabled.  Next  three  procedures:  UpdateEvent,  TerminateScope  and  UpdateScope  are 
invoked  in  sequence.  The  EVM  runtime  system  uses  a  discrete  scheduler,  i.e.,  the 
scheduler  is  invoked  only  at  a  certain  periodic  event,  tick.  If  the  input  event  corre¬ 
sponds  to  tick  the  scheduler  is  invoked. 

The  procedure  UpdateEvent  (Algorithm  2)  updates  the  counter  for  the  events  in  the 
event  filter  in  the  following  way:  for  each  event  instance  i  =  {e,s,f),  if  either  (1)  /  G 
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{A,  R}  or  (2)  /  =  F  and  the  event  instance  occurs  in  a  leaf  scope,  then  the  event  instance 
i  is  updated  by  next(i,  e')-  If  the  updated  event  instance  i  is  enabled  and  the  form  of 
the  event  instance  is  a  sap  then  the  trigger  queues  of  all  descendent  scopes  are  emptied. 


Algorithm  1:  EVM-main 


Algorithm  2:  UpdateEvent 


loop 

wait  for  input  e' 

disable  trigger-related  interrupts 
UpdateEventCounter(EventFilter,e') 
TerminateScope  {EventFilter,e') 
ReactScope  (EventFilter,e') 
enable  trigger-related  interrupts 
if  e’  is  tick  event  then 

invoke  system  scheduler  on  Active- 
TaskSet 
end  if 
end  loop 


for  all  scopes  i-  e  EventFilter  do 
for  all  event  instances  i  e  i  do 

if  (/  =  A,R)  V  ((/  =  F)A  {s  is  a  leaf)) 

then 

next(i,  e'y, 

if  (i  is  enabled)  A{f  =  A)  then 
RemoveTriggers  from  sub-tree 
rooted  by  i- 

end  if 
end  if 
end  for 
end  for 


Next  the  procedure  TerminateScope  (Algorithm  3)  is  invoked.  The  procedure  termi¬ 
nates  all  terminating  scopes  and  terminates  the  tasks  that  are  released  in  the  scope.  A 
scope  is  terminating  if  it  is  a  leaf  scope  and  its  terminating  event  instance  is  enabled. 
First,  a  terminating  scope  is  terminated  by  removing  the  corresponding  node.  Sec¬ 
ond,  for  each  task  instance  {t,po,Sp-)  of  the  removed  scope,  the  port  values  of  po  in 
E  are  updated  by  applying  task  t  to  the  port  values  of  p,  given  by  Sp^  Third,  if  the 
removed  scope  is  a  s  ap-parallel,  then  the  trigger  queues  of  all  its  sibling  scopes  and 
their  descendants  are  emptied.  The  procedure  is  iterated  until  there  are  no  terminating 
reactions. 


Algorithm  3:  TerminateScope 

Algorithm  4:  ReactScope 

while  there  exists  a  terminating  scope 

while  there  is  a  reacting  scope  i-  e  Event- 

s  CzEventFilter  do 

Filter  do 

terminate  the  tasks  released  in  s 

the  enabled  trigger  be  (i,m,p,r) 

terminate  i 

if  m  =  whenever  then 

if  i-  is  bound  by  a  sap  parallelism  then 

reset(i) 

RemoveTriggers  from  the  siblings  of  i- 

trigger  is  reinserted  in  the  trigger 

and  the  scopes  in  the  sub-tree  rooted  by 

queue 

the  siblings 

end  if 

end  if 

for  all  reaction  block  /  in  r  do 

end  while 

create  a  new  scope  s'  for  / 
/Mterpreterf address  of  /) 

end  for 
end  while 

Next  the  procedure  ReactScope  (Algorithm  4)  invokes  the  enabled  triggers  for  each 
reacting  scope.  A  scope  is  reacting  if  it  is  a  leaf  scope  and  its  trigger  queue  contains 
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a  trigger  with  an  enabled  invoking  event  instance  /;  this  is  called  an  invoked  trigger. 
Let  the  first  invoked  trigger  be  g  =  {i,m,p,r),  then  a  set  of  scopes  are  added  to  the 
reacting  scope  as  children  —  one  for  each  reaction  block  of  r.  Moreover,  the  trigger  g 
is  removed  from  the  queue,  and  if  m  =  whenever,  then  the  new  trigger  (reset(i),m,p,r) 
is  appended  at  the  end  of  the  trigger  queue. 

The  scope  of  each  new  node  is  computed  by  executing  the  corresponding  EVM  code 
at  the  address  given  by  r  by  the  pseudo-code  shown  in  Algorithm  5:  the  termination 
event  instance  of  the  new  scope  is  determined  by  the  until  event  of  the  corresponding 
reaction  block;  the  trigger  queue  of  the  new  scope  contains  one  trigger  for  each  when 
and  whenever  statement  in  the  order  of  the  statements;  the  ready  set  of  the  new  scope 
contains  one  task  instance  for  each  release  statement  where  the  values  of  the  task 
input  ports  are  taken  from  E;  and  the  parallelism  of  the  new  scope  is  determined  by 
whether  the  invoked  reaction  blocks  are  composed  with  a  sap-  or  wait -parallelism. 
The  conditionals  associated  with  the  trigger  and  the  release  statements  are  evaluated 
with  standard  JVM  instructions  and  omitted  here  for  simplicity.  The  procedures  Port- 
Value  and  EventValue  access  the  memory  location  of  a  port  and  an  event  respectively. 
The  procedure  shown  in  Algorithm  4  is  repeated  until  there  exists  no  reacting  scopes. 
The  handling  of  an  input  event  ends  here  and  EVM  starts  waiting  for  the  next  event. 
However  if  the  last  event  is  a  tick  event,  the  system  scheduler  is  invoked  and  a  new 
task  starts  its  execution  until  the  next  tick  event  occurs. 


Algorithm  5:  Interpreter 

while  PC/  i-  do 

op  :=  GetInstruction(PC) 
it  op  =  trigger  {i,m,p,r)  then 
Q:=QU{i,m,p,r) 
else  if  op  =  release  (f)  then 

r  :=  r  u  f 

else  if  op  =  getport(p,o)  then 

j  :=  Sli'P];  S[SP]  :=  PortValue{p,o  +  sy, 
else  if  op  =  putport(p,o)  then 
i:=S[5'P];v:=5[5'P-l]; 

PortValue{p,  o  -|-  j)  :=  v;  SP  :=  SP  —  2 
else  if  op  =  getevent(e,o)  then 

j  :=  S[SP] ;  S[SP]  :=  EventValue{e, o  j) ; 
else  if  op  =  enterscope  then 
g  :=0;  r  :=0; 

else  if  op  =  exitscope  then 
PC:=± 
else 

Java  code  interpreter 

end  if 
end  while 
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Chapter  4 

EVM  code  generation  and 
rnn-time  implementation 


This  section  discusses  the  xGlOTTO  tool  chain  comprising  the  compiler  and  the  EVM 
run-time  implementation.  The  prototype  implementation  has  been  shown  in  Figure  4. 1 . 
The  compiler  checks  the  syntactic  requirements  and  perform  the  three  analyses  de¬ 
scribed  earlier  and  the  run-time  implementation  executes  the  program  with  the  event 
filter,  the  modified  E  machine  and  the  scheduler.  The  sections  concludes  with  an  dis¬ 
cussion  on  the  possible  extensions  of  the  xGlOTTO  tool  chain. 

4.1  Compile-time  implementation. 

An  application  is  specified  using  the  xGlOTTO  program.  The  xGlOTTO  compiler  (Fig¬ 
ure  4.1)  checks  for  the  syntactic  correctness  and  then  checks  for  presence  of  races;  if 
race  exists  the  trace  of  event  leading  to  the  race  is  provided.  If  no  race  is  detected 
the  time  safety  check  is  carried  out  relative  to  the  worst-case-execution-time  (WCET) 
mapping  of  the  tasks  and  the  real  time  platform.  If  the  program  is  not  schedulable,  the 
information  is  passed  for  further  iteration;  otherwise  a  scheduling  strategy  is  provided 
to  the  run-time  system.  The  code  generator  produces  code  which  can  be  divided  into 
two  parts,  reaction  code  and  task  code.  Reaction  code  is  essentially  augmented  JVM 
instructions,  whereas  task  code  is  JVM  instructions. 


4.2  Run-time  Implementation. 

The  xGiotto  run-time  environment  (Figure  4.1)  consists  of  three  interacting  com¬ 
ponents:  the  event  filter,  the  modified  E  machine,  and  the  scheduler.  The  event  filter 
implements  the  event-scoping  mechanism  and  presents  the  filtered  events  to  the  E  ma¬ 
chine.  The  implementation  of  the  event  filter  is  same  as  discussed  in  the  last  section. 
At  run-time,  the  occurrence  of  an  event  is  processed  by  the  event  filter.  The  event  fil¬ 
ter  computes  the  event  transition  and  the  termination  transitions  on  the  tree  of  event 
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Compile  Time  Implementation 


Metropolis  Platform 
Exploration 


Run  Time  Implementation 


Figure  4.1:  Implementation 


scopes  and  gives  to  the  E  machine  a  set  of  EVM  code  addresses,  which  correspond 
to  the  invoked  reaction  blocks.  The  EVM  interprets  the  EVM  code,  thus  perform¬ 
ing  the  reaction  transitions.  The  EVM  code  instructions  may  release  new  tasks  to  the 
scheduler  and  enable  new  triggers.  When  all  invoked  reactions  have  been  processed 
by  the  machine,  the  system  scheduler  chooses  a  task  to  execute  from  the  ready  set  of 
the  active  event  scopes,  and  whenever  such  a  task  completes,  the  EVM  is  notified.  In 
addition,  the  EVM  monitors  the  running  tasks  by  detecting  task  overruns  (time-safety 
violations).  If  a  task  overrun  is  detected  (i.e.  if  a  task  termination  event  arrives  before 
the  task  completes),  a  run-time  exception  is  generated.  The  platform  interacts  with 
the  environment  through  actuators  and  sensors.  The  actuators  are  driven  by  the  task 
outputs  and  the  sensors  generate  atomic  events  (interrupts),  which  are  handled  by  the 
event  filter.  The  prototype  is  implemented  in  Java  and  is  able  to  run  any  xGlOTTO 
program  and  to  interprets  a  subset  of  the  JVM  bytecode  [13]. 

OSEKWorks  is  a  real  time  platform  from  WindRiver  which  implements  the  OSEK 
standard  [10]  for  embedded  applications  in  the  domain  of  automotive  and  industrial 
automation.  Currently  work  is  under  progress  to  port  the  EVM  on  OSEKWorks  and 
implement  the  AER  controller  (discussed  in  the  next  section). 

4.3  Extensions 

xGioTTO  is  being  integrated  with  Metropolis  [14].  Metropolis  is  a  unified  framework 
which  allows  the  simulation  and  exploration  of  different  runtime  platforms.  By  incor¬ 
porating  xGiotto  in  the  metropolis  framework  we  allow  the  flexibility  of  studying  and 
exploring  the  embedded  software  design.  The  xGlOTTO  compiler  generates  Metropo- 
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lis  meta-model  descriptions  (Figure  4.1)  of  the  reactivity  and  of  the  tasks.  Given  a 
description  of  the  platform  and  its  environment,  Metropolis  is  capable  of  analyzing  the 
platform  and  generates  a  worst-case-execution-time  mapping  for  the  tasks. 

The  Ptolemy  project  [15]  studies  modeling,  simulation,  and  design  of  concurrent,  real¬ 
time,  embedded  systems.  It  focuses  on  the  use  of  well-defined  models  of  computa¬ 
tion  and  how  heterogeneous  mixture  of  such  models  of  computations  can  be  used  for 
modelling  and  analyzing  embedded  systems.  In  the  future  we  are  interested  in  imple¬ 
menting  an  xGiotto  domain  in  Ptolemy  to  further  investigate  the  embedded  system 
applications  design  and  development. 

Simulink  is  a  well  known  simulation  and  code-generation  environment  for  control  ap¬ 
plications  in  automotive  and  avionics  domain.  Simulink  is  used  in  association  with 
code  generators  for  real-time  systems  like  Real-Time  Workshop  [16].  In  the  future  we 
would  like  to  explore  the  integration  of  xGlOTTO  and  Simulink  as  has  been  done  in 
Giotto-Simulink  translator  [17]. 
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Chapter  5 

Case  Study 


The  case  study  presents  a  problem  from  the  automotive  industry.  While  an  engine  is  in 
motion  the  engine-fuel  system  needs  to  inject  fuel  into  the  combustion  engine  with  the 
optimal  amount  of  air  [18].  This  is  commonly  known  as  air-fuel  ratio  (APR)  control 
in  the  automotive  domain.  The  operation  is  very  sensitive  to  the  timing  of  the  APR 
controller.  The  APR  controller  updates  the  fuel-injectors  (actuators)  with  the  amount 
of  fuel  to  be  injected  in  the  next  engine  cycle.  The  fuel  is  sprayed  to  the  intake  ports 
once  the  valves  are  closed  and  with  enough  time  allowance  so  that  the  mixture  forms 
before  the  valves  open.  The  valve  timing  depends  upon  the  engine  speed;  this  forces  the 
APR  controller  to  issue  updates  at  aperiodic  time  intervals.  The  right  half  of  Pigure  5.1 
shows  the  APR  controller.  There  are  two  shafts  in  the  engine:  crank  and  cam  shaft.  Por 
every  rotation  in  the  wheel,  the  cam  rotates  once  and  crank  rotates  twice.  There  is  only 
one  teeth  in  the  cam  shaft.  There  are  six  teeth  slots  in  the  crank.  However  one  slot  is  left 
empty  to  synchronize  with  the  cam  shaft.  On  receiving  signal  (which  is  synchronized 
with  the  arrival  of  the  teeth),  each  injector  injects  a  certain  amount  of  precalculated 
amount  of  fuel.  Por  each  engine  cycle  an  injector  sprays  once.  Initially  we  assume 
that  the  engine  is  at  top  dead  center  (as  illustrated  in  Pigure  5.1).  At  this  point  the 
APR  controller  computes  how  much  fuel  is  needed  for  the  cylinder  in  the  next  engine 
cycle  -  and  the  amount  of  fuel  each  injector  needs  to  inject.  In  this  discussion  the 
injector  response  time  and  other  non-linear  effects  have  been  omitted.  The  cam  shaft 
pulse  is  used  as  a  reference  to  obtain  the  numbering  of  the  crank  shaft  teeth  (which 
we  have  chosen  to  be  5  H-  1  missing)  as  shown  in  the  figure.  Por  our  case  only  three 
injectors  have  been  considered;  however  they  can  be  increased  to  any  number  allowed 
by  the  dynamics  of  the  system.  The  crank  shaft  teeth  is  converted  to  pulses  via  the 
signal  conditioning  circuitry.  The  i-th  injector  injects  at  the  i-th  teeth  pulse  as  shown. 
When  the  crank  shaft  reaches  the  end  of  the  engine  cycle,  denoted  by  tooth  number 
10,  the  calcInjPar  routine  is  initiated  which  calculates  the  fueling  parameters  for  the 
next  engine  cycle.  The  computation  has  to  be  completed  before  the  arrival  of  the  tooth 
number  1.  At  this  instance  the  injection  for  first  injector  is  initiated.  The  fuel  parameter 
is  actually  scaled  to  the  length  of  a  pulse  proportional  to  the  mass  to  be  injected.  Thus 
the  fuel  injection  can  be  represented  by  a  pulse  of  width  proportional  to  the  mass  of 
fuel  to  be  injected  by  the  respective  injector. 
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iniector  1  injector  2  injector  3 


Crank  shatl  Camshaft 


Figure  5.1:  AFR  Controller  —  Implementation 


xGiotto  Program 

An  xGioTTO  program  that  simulates  the  behavior  of  the  controller  has  been  shown  in 
Figure  5.2.  The  controller  presented  is  used  when  the  engine  is  warm,  running  in  fourth 
gear  and  the  minimum  speed  of  the  system  is  1000  rpm.  This  implies  that  between  each 
slot  of  crank  shaft  there  is  a  minimum  time  gap  of  5ms  (one  engine  revolution  every 
60ms).  The  event  tick  in  the  program  denotes  1  ms  event.  There  are  three  fuel 
ports  f  1 ,  f  2 ,  f  3  for  the  three  injectors  and  are  of  type  integer.  The  i-th  fuel  port  is 
updated  with  the  mass  of  fuel  to  be  injected  for  the  i-th  injector.  There  are  three  (one  for 
each  injector)  pulse  ports  and  simulate  the  fuel  injection.  The  ports  pi ,  p2 ,  p3  are 
pulse  ports  and  are  boolean  ports  which  are  normally  grounded  (or  reset).  They  are  set 
to  high  (or  true)  for  the  time  equal  to  the  length  of  the  pulse  (i.e.  the  value  stored  in  the 
corresponding  fuel  port)  to  simulate  the  injection.  In  actual  implementation  the  tasks 
set  and  reset  will  correspond  to  the  closing  and  opening  of  the  valve  for  an  injector. 
The  task  dec  checks  for  the  remaining  length  of  the  pulse;  in  real  implementation  it 
will  simulate  the  pulse  generation  technique  to  inject  the  required  mass  of  fuel.  The 
controller  starts  with  the  signal  synch  which  is  invoked  at  the  synchronization  of  TDC 
for  the  crank  and  cam  shafts.  At  the  signal,  reaction  mode  start  is  invoked  which 
calls  the  reaction  controller  once  for  each  revolution  of  the  wheel  and  thus  for  the 
arrival  of  every  10  teeth  (whenever  a  teeth  passes  the  TDC  a  teeth  event  is  generated) 
of  the  crank  shaft.  Once  controller  is  invoked,  the  task  Calcin  jPar  is  released 
to  calculate  the  mass  of  fuel  to  be  injected  for  each  of  the  injector  and  updates  the 
three  fuel  ports  f  1,  f2  and  13  by  the  arrival  of  the  next  teeth.  This  implies  that  at 
the  worst  case  it  takes  10ms  for  its  computation  (the  toothless  slot  is  included  here) 
and  is  expressed  by  the  deadline  [  10ms  :  teeth] .  At  the  arrival  of  the  first  tooth 
on  the  cycle  the  three  injectors  (the  three  reaction  blocks  channell ,  channel2 , 
channel3)  are  invoked  in  parallel.  The  reaction  channel/  handles  the  injection  of 
the  i-th  injector.  For  the  i-th  injector,  the  injection  should  start  at  the  arrival  of  the  i-th 
teeth;  so  the  task  set  sets  the  value  of  the  pulse  variable  of  the  injector  at  the  i-th 
teeth.  For  the  block  channel2  an  initial  gap  of  a  tooth  is  provided  and  then  set  is 
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program  Air-Fuel-Ratio-Controller  { 

port 

/*  fuel  ports  */ 

int  fl;  int  f2;  int  f3; 

/*  pulse  ports  */ 

bool  pi;  bool  p2;  bool  p3; 

event 
int  synch; 
int  stop; 
int  teeth; 

task  set  {)  output  (int  o) 

{  o  =  true;  } 

task  reset  (int  i)  output  (int  o) 

{  if  (i  ==  0)  o  =  false;  } 

task  dec  (int  i)  output  (int  o) 

{if  (i  >  0)  o  =  i  -  1;  } 

task  calcFuellnj  () 
output  (int  fl,  int  f2,  int  f3) 

{/*  Fuel  Parameter  Computation  */} 

react  channellO  { 
when  [now] 

(release  set  ()  (pi);}  until  [Itimej; 

loop 

react  (release  reset  (fl)  (pi) ; 

release  dec  (fl)  (fl); 

}  until  [time] 

end; 

}  until  [int  e] 


react  channel2()  { 

when  [now]  react  {}  until  [5time  :  teeth]; 
when  remember  [Stime  :  teeth]  react 
(release  set  ()  (p2);}  until  [time]; 

react  { 

loop  react  (release  reset  (f2)  (p2); 

release  dec  (f2)  (f2); 

}  until  [time] ; 

end;  } 

}  until  [int  e] 


react  channel3()  { 

when  [now]  react  {}  until  [lOtime  :  2teeth] ; 
when  remember  [lOtime  :  2teeth]  react 
(release  set  ()  (p2);}  until  [time]; 

react  { 

loop  react  (release  reset  (f3)  (p3); 

release  dec  (f3)  (f3); 

}  until  [time] ; 

end;  } 

}  until  [int  e] 

react  calcFuelO  { 
release  calcFuellnj ( )  (fl,  f2,  f3)  ; 

}  until  [int  e] 

react  controller ()  { 
when  [now]  react  calcFuelO 

until  [lOtime  :  teeth]; 
when  remember  [teeth] 

react  channellO  until  asap  [50time  :  9teeth]  |  | 

react  channel! ()  until  asap  [SOtime  :  9teeth]  | | 

react  channel! ()  until  asap  [50time  :  9teeth] ; 

}  until  [int  e] 

react  start  ( )  { 
when  [now]  react  controller () 

until  remember  [lOteeth]; 
whenever  remember  [lOteeth] 

react  controllerO  until  remember  [lOteeth]; 

}  until  [int  e] 

(when  [synch]  react  start ()  until  asap  [stop];} 

} 


Figure  5.2:  AFR  Controller  —  xGlOTTO  program 


released  on  the  pulse  port  p2  (with  a  LET  of  1ms).  Following  this  a  loop  is  started 
which  repeats  every  ms  and  schedules  tasks  dec  and  reset.  The  implementation  of 
the  controller  on  OSEK  is  currently  under  development. 
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Chapter  6 

Conclusion 


In  this  report  we  presented  the  Embedded  Virtual  Machine.  The  EVM  simplifies  im¬ 
plementing  and  porting  of  xGlOTTO  to  any  other  RTOS.  The  virtual  machine  code  is 
simple  enough  to  be  ported  to  any  RTOS.  This  is  not  the  most  optimal  approach  since 
it  involves  the  interpretation  on  top  of  the  hosting  RTOS.  An  optimal  but  complex  solu¬ 
tion  would  be  to  implement  the  EVM  “bare  bone”  on  the  target  platform,  reducing  the 
overhead  to  the  minimum.  In  this  paper  we  propose  a  modified  Java  Virtual  Machine 
(JVM).  However  the  concept  can  be  applied  to  any  other  instruction  set.  Choosing  the 
JVM  as  a  starting  point  for  our  investigation  allowed  us  to  have  access  to  and  be  in¬ 
spired  by  several  different  implementation  of  the  original  JVM,  such  as  the  JikesVM, 
JamaicaVM,  aJile  and  JBed  to  name  a  few. 

In  particular  we  were  inspired  by  the  leJOS  [19]  and  TinyOS  [20]  systems.  The 
TinyOS  system  is  targeted  towards  sensor-networks  applications  implemented  in  nesC 
and  leJOS  is  targeted  towards  implementing  applications  for  the  Lego  Mindstorms. 
Both  the  systems  are  characterized  by  their  succinctness  (15Kb  for  leJOS  and  4Kb  for 
TinyOS)  and  are  targeted  to  run  on  microprocessors  with  a  very  small  memory  footprint 
(the  Hitachi  H8  for  leJOS,  and  the  Atmel  AVR  for  TinyOS). 

Moreover  in  this  work  we  attempted  to  bring  some  of  the  threading  functionality  usu¬ 
ally  found  in  real-time  operating  system  at  the  instruction  level.  This  can  be  compared 
to  the  introduction  of  object-oriented  functionality  (such  as  object  instantiation)  on  the 
JVM. 
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